System and Method Using A Simplified XML Format for Real-Time Content Publication

ABSTRACT

A system and method for delivering content in real-time using advanced messaging technology that reduces the risk of content being lost or dropped in transmission. The system and method utilize a custom, simplified XML format to deliver real-time textual, numeric, and metadata content directly to subscribers. The XML tag set specifies all of the information needed to package, process, and distribute real-time content messages and includes an advanced tagging structure that allows granular content customization. Messages are built on the fly using multi-channel data processing techniques. The XML delivery system and method offers an array of real-time market-specific page-based “Alert” services and aggregated newswires with accompanying real-time numeric data feeds. These feeds contain proprietary assessments and other price data across a broad spectrum of global and regional commodity markets, including oil, petrochemicals, metals, electric power, natural gas, coal, and risk.

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) to U.S.Provisional Application Ser. No. 61/369,490, filed Jul. 30, 2010, thedisclosure of which is hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to systems and methods of distributinginformation items, or content, to channel partners. More particularly,the present invention is directed to a system and method of receiving,packaging, and delivering XML market data to a plurality of subscribersin real-time.

BACKGROUND OF INVENTION

Electronic content publication systems are used to publish digitalinformation items to a plurality of subscribing entities. Thepublication systems provide information items to multiple, physicallyseparate computerized devices over one or more digital computernetworks. These information items may include textual, numeric, or otherforms of data, such as, stock quotes, financial data, weather reports,news items, etc. These information, or content, publication systems maybe used to disseminate information from a variety of electronic contentproviders to a variety of subscribing entities (subscribers, vendors,partners), via the interne or other communications networks.

Industry-standard price assessments are a critical element of short- andlong-term commodities contracts worldwide. This information may bepublished in textual form along with news, market commentary,fundamental data and other useful content. Several product and deliveryvehicles may be utilized, such as real-time page-based “Alert” services,as well as end-of-day newswires/newsletters, traditional printnewsletters covering different industry segments, or network basedcontent publication services.

There are a number of challenges that content publication systems mustovercome. For example, incoming data must be formatted, in someinstances combined, and then associated with the appropriate subscribersentitled to receive that data (known as “packaging” the data). Withcertain types of data it is critical that each subscriber receive thesame data at substantially the same time. Additionally, contentpublication systems must be able to recognize and deal with failures ininformation delivery. Furthermore, subscribers do not use the data inthe same ways or run the same types of platforms making establishing astandardized data format difficult.

Existing systems store incoming data for later retrieval anddissemination. At certain intervals, the data is retrieved, associatedwith the appropriate subscribers, and delivered to subscribers. However,existing systems do not receive multiple types of data and package anddistribute it in real-time, i.e., package and distribute a message inresponse to the receipt of a input data massage. Further, in existingsystems, critical market data may be lost or dropped before beingdelivered to subscribers, due to, for example, network errors orproblems with subscribers' servers. In the event that market data cannotbe delivered to a subscriber, existing systems do not have thecapability to preserve the data until it can be delivered.

Accordingly, there exists a need for an improved system and method forreliably delivering market data to a plurality of subscribers inreal-time.

BRIEF SUMMARY OF THE INVENTION

Aspects of the present invention relate to systems and methods forelectronically distributing news, price information, and market dataover the internet or other communications network in a simplified,extensible markup language (XML) format to a plurality of subscribers.

According to an embodiment of the present invention, a system isconfigured to receive textual and numeric content from at least onesource, package the content for delivery to at least one of a pluralityof subscribing entities, and publish or otherwise deliver the contentvia the internet or other communications network. Subscribing entitiesmay include, for example, individual or corporate subscribers, partners,customers, news or information vendors, or any third party informationrecipient. Numeric content may include numerical analysis such asassessments and other data. For instance, numerical content may includeclosing market prices and fundamental statistical data as well astime-series data for charting or graphing. Textual content may includenews, articles, market commentary, transactions, “market heard” pages,statistics tables, and proprietary assessment and fundamentals tables.

Preferably, the system comprises one or more computers configured to usea simplified XML tag set to deliver real-time textual and numericcontent directly to subscribers in accordance with a real-timepermissioning system. This custom tag set specifies all of theinformation needed to process, package, and distribute real-time contentmessages and includes an advanced tagging structure that allows granularcontent customization.

Embodiments of the present invention offer flexible, reliable and fastdelivery of real-time content, including page-based “Alert” services,selected newswires, and proprietary real-time numeric data. Thesefeatures may be accomplished by combining enterprise messagingtechnology with an XML message schema. According to one aspect of theinvention, data is normalized through the use of at least one filter orflow process and delivered in a standardized format with enoughflexibility to allow for future changes. The simple, clean messageformat of the present invention improves timeliness and reducesprocessing errors over legacy formats and guarantees messaging thatreduces the risk of content being lost or dropped in transmission.

According to aspects of the present invention, the system and methodprocess and package messages according to Execution Groups, whichcontain named groupings of message flows. A message flow may beunderstood as a sequence of nodes, which define the processing steps runby the delivery system of the present invention when an input message isreceived. For example, a node can represent the set of actions executedby a computer program or processor that define a processing step.

In accordance with another aspect of the invention, enterprise customerscan directly ingest content into their workflow. Furthermore, theinvention allows content to be streamed that has traditionally not beendelivered by real-time platforms, thereby creating a single consolidateddistribution platform for current and future content.

The present invention provides a real-time content distribution solutionusing advanced messaging technology that reduces the risk of contentbeing lost or dropped in transmission.

In accordance with another aspect of the invention, an array ofreal-time market-specific page-based “Alert” services and aggregatednewswires with accompanying real-time numeric data feeds are provided.These feeds contain proprietary assessments and other price data acrossa broad spectrum of global and regional commodity markets, includingoil, petrochemicals, metals, electric power, natural gas, coal, andrisk. This content may be delivered using one of three basic XML messageformats—textual, numeric or metadata. Additional embodiments of thepresent invention include metadata and numeric analytics data feeds thatinclude real-time and historic market data. These bulk data feedsprovide customers greater flexibility on how and where to leverage theanalytics content.

In accordance with another aspect of the invention, the sourceinformation comes from a content publication or generation system, whichis used to publish information related to a wide range of markets. Thesource information is in a standardized format, typically XML 1.0, witha pre-defined set of tags. This information is routed to a deliverysystem over a communications network, such as an IP network via an IPbased messaging protocol, then transformed and processed using a definedset of rules implemented in a rule based engine called a TransformPublish Filter (TPF). The delivery system may then distribute packagedcontent, or authorize the publication of content messages, based upon aset of distribution rules, such as a subscription permissioning system.For instance, message data, in a second format, usually XML 2.0, isforwarded to the Subscriber hosts over an IP network using the messagingprotocol.

The design of the delivery system provides for ‘end to end’ globaldelivery, by leveraging standard messaging to deliver content via publicnetworks. The message flow system leverages the messaging system todeliver the feed either over the public network or over a privatenetwork.

In accordance with another aspect of the invention, the TPF rule engineallows real-time application of textual and numeric Business Rules andchanges. The message flow architecture allows for maintainingsubscription details in real time by processing a permission file asdesigned by a fulfillment system. For example, a Load Permission Fileflow can process the permission file in real time whenever there is achange in the incoming permission file by processing the details andupdating the database. The fulfillment system may be any externalapplication that supplies a permission file, which may contain, forexample, individual subscriber entitlement and package information. Thisinformation may be used by the TPF to permission, package, anddistribute content in real-time.

In accordance with another aspect of the invention, the XML structureallows flexibility and agility to customize content in real-time. Themessage flow architecture allows for enabling or disabling certain tagsfor a specific partner and for customizing the content to differentpartners based on their subscription or preference information.

In accordance with another aspect of the invention, an XML deliverysystem allows for a complete audit trail, logging, and alert capabilityin real-time, end to end, up to the delivery point to the end user. Forinstance, a Send To Audit flow can capture the audit information and aPerfmon results flow can capture the performance details.

In accordance with another aspect of the invention, content isprioritized for optimal delivery. Different types of messages can beassigned different priorities by the message flow allowing the system todeliver the messages on specified criteria, such as message type orcontent, rather than in a “first in, first out” format. For example,Price or Numeric messages may be assigned a higher priority than Textualmessages so that in the event that two messages are simultaneously beingprocessed, the price or numeric message could be delivered first.

In accordance with another aspect of the invention, the XML structuredescribed herein can function as an industry standard for commodity newsand market data distribution. As will be described in greater detailbelow, the Document Type Definition (DTD) for the XML structure isunique, and structured to capture the necessary commodity news andmarket data.

In accordance with another aspect of the invention, compliance with theXML Standard may be enforced in real-time. The message flow can beconfigured to raise an exception if an XML message is not in accordancewith XML standards. For example, an exception would be raised if an XMLmessage were ill-formed XML without proper closing tags.

In accordance with another aspect of the invention, metadata isdistributed at a desired frequency with all attributes necessary fordata ingestion. A metadata flow publishes the price metadata as and whennecessary. For example, metadata could be sent once a week or on ademand/need basis.

In accordance with another aspect of the invention, multiple data typescan be processed simultaneously and yet maintain the order of sequence.Specifically, the message flow can process multiple data types inparallel, such as textual, price, and metadata, by filtering theincoming message type and routing them to their associated flows. Adedicated flow, such as a Check Content type flow, can accommodate thisfunctionality.

In accordance with another aspect of the invention, the tag value codestructure design and TPF rule engine together allow for content bundlingin real-time. The content delivered to a subscriber can be customizedwith the ability to bundle only relevant information intended for aparticular subscriber instead of sending all the content to all thesubscribers. For instance, exemplary nodes “Build Textual data” and“Build Price data” can be configured to check the permissioning for eachsubscriber and identify the list of subscribers who would get themessage. The nodes can also build the messages individually using the<sendTo> tag, with different values, such as: <sendTo>vendor1</sendTo>,<sendTo>vendor2</vendor2>, and <sendTo>vendor3</vendor3>, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate various embodiments of the presentinvention and, together with the description, further serve to explainthe principles of the invention and to enable a person skilled in thepertinent art to make and use the invention. In the drawings, likereference numbers indicate identical or functionally similar elements.

FIG. 1 is a logical diagram showing the transformation and publicationof content to various partners according to an embodiment of the presentinvention.

FIG. 2 is a diagram showing the content feed process flow according toan embodiment of the present invention.

FIG. 3 is a diagram showing an exemplary high-level architectureaccording to an embodiment of the present invention.

FIG. 4 is a diagram showing the check content type process flowaccording to an embodiment of the present invention.

FIG. 5 is a diagram showing the error handler process flow according toan embodiment of the present invention.

FIG. 6 is a diagram showing the load permission file process flowaccording to an embodiment of the present invention.

FIG. 7 is a diagram showing the load perfmon results process flowaccording to an embodiment of the present invention.

FIG. 8 is a diagram showing the send to audit process flow according toan embodiment of the present invention.

FIG. 9 is a diagram showing the load audit data log process flowaccording to an embodiment of the present invention.

FIG. 10 is a diagram showing the structure of an exemplary XML elementhierarchy according to an embodiment of the present invention.

FIG. 11 is an XML Simple Tag Element Hierarchy Diagram in accordancewith an embodiment of the present invention.

FIG. 12 is an XML Textual Element Hierarchy Diagram in accordance withan embodiment of the present invention.

FIG. 13 is an XML Numeric Element Hierarchy Diagram in accordance withan embodiment of the present invention.

FIG. 14 is an XML Metadata Element Hierarchy Diagram in accordance withan embodiment of the present invention.

FIG. 15 is a logical network diagram of a generalized contentpublication system in accordance with an embodiment of the presentinvention.

FIG. 16 is a logical diagram of an XML delivery system in accordancewith an embodiment of the present invention.

FIG. 17 is a logical diagram of the Execution Groups in an XML deliverysystem in accordance with an embodiment of the present invention.

FIG. 18 is a logical diagram of a ProcessEWSFeed Message Flow inaccordance with an embodiment of the present invention.

FIG. 19 is a logical diagram of a TextualFlow Message Flow in accordancewith an embodiment of the present invention.

FIG. 20 is a logical diagram of a SubscriberProcessing Message Flow inaccordance with an embodiment of the present invention.

FIG. 21 is a logical diagram of a NumericFlow Message Flow in accordancewith an embodiment of the present invention.

FIG. 22 is a logical diagram of a NumericSubscriberProcessing MessageFlow in accordance with an embodiment of the present invention.

FIG. 23 is a logical diagram of a MetaDataFlow Message Flow inaccordance with an embodiment of the present invention.

FIG. 24 is a logical diagram of a LoadPartner2QueuesMapping Message Flowin accordance with an embodiment of the present invention.

FIG. 25 is a logical diagram of a LoadPartnerFilteringMapping MessageFlow in accordance with an embodiment of the present invention.

FIG. 26 is a logical diagram of a LoadSubscriberQMapping Message Flow inaccordance with an embodiment of the present invention.

FIG. 27 is a logical diagram of a LoadXMLDDTimeZoneMapping Message Flowin accordance with an embodiment of the present invention.

FIG. 28 is an illustration of exemplary price output messages inaccordance with an embodiment of the present invention.

FIG. 29 is an illustration of exemplary news story output messages inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In accordance with the present invention, the integration of multipledata types is supported. Multiple unique sets of numeric and textualdata may be distributed using a similar structure but different tagsets.

For example, News & Pricing data contains assessments and other datasuch as closing market prices and fundamental statistical data and istypically distributed using a numeric message format. Use of a numericmessage format can support, for example, storage of time-series data forcharting, analysis, or other purposes.

Textual report messages may come in a variety of page sizes to supportthe distribution of news, market commentary, transactions, andproprietary assessment and fundamentals tables that are pertinent to adefined market. For legacy distribution requirements, a variable lengthformat is used to distribute news articles, market commentary, andlegacy newswires, and a fixed length format for proprietary assessmenttables, statistical tables, and transaction or “market heard” pages.

In accordance with the present invention, at least two unique sets ofmetadata messages can be distributed and associated with these datatypes. For instance, a first for News & Pricing data and a second forAnalytics data. Both message types include permissioning informationalong with symbol definitions and attributes that are vital to ingestingdata. The metadata for Analytics content provides additional informationfor its associated numeric messages.

In accordance with an embodiment of the present invention shown in FIG.1, a rule-based engine known as a Transform Publish Filter engine (TPF)101 is provided. The TPF may be implemented on one or more computersvia, for instance, algorithms comprising computer-executableinstructions stored on non-transitory computer-readable media. The TPFfunctions to process, transform and enrich different types of content,including numerical and textual data. Content is received from a contentintegration source 103 via a messaging server 105. Once the data hasbeen transformed and processed by the TPF 101, the content isdistributed to a plurality of vendors or partners 107 via a messagingserver 109.

The TPF 101 applies as series of rules in Process Flow 111 whenreceiving, transforming, and publishing or otherwise distributingmessages. For example, the TPF 101 may be configured to support multipleincoming message types and identify incoming message types through adedicated flow which, for example, distinguishes between andappropriately routes textual, numeric, and meta data to appropriatenodes. Further, a flow of the TPF may set the message priority fordelivery, transform the message to a Standard XML format, and formatvendor specific content before delivery. Further, the TPF may include aflow to apply permission rules. For instance, the applied permissionrules may be based on a received permission message. Moreover, the TPFcan be configured through a series of flows to dynamically update thepermission rules whenever there is a new permission message available,log errors, exceptions, and/or un-subscribed messages, and alert orcommunicate information to a support team.

Textual and numeric data from a content source are sent to the feedqueue on a TPF server. The TPF server may include a number of executiongroups. According to an embodiment of the present invention, there arefour execution groups in the TPF engine.

The first, ExecutionGroup1, handles all application messages. Once themessage type is identified, for instance as textual, numeric, ormetadata, the message is routed to the corresponding node in the ProcessFlow 111, with specific tags determining its fulfillment criteria (e.g.,information regarding how the data should be packaged and delivered). Ifthere are any errors in the XML tag structure, the messages are sent tothe error queue and no further processing is done. If the particularitem is subscribed to by any partner 107, individual messages arecreated for each partner with the subscribed elements in a correspondingXML message. Once all the fulfillment details are identified and mapped,the individual messages for those partners are sent to a queue ordistribution list based on these criteria.

The second, ExecutionGroup2, is directed to analytics data processing.Analytics data may arrive via drive mapping as a CSV file, for example.These files are sent to a feed queue and the message flow picks up thosemessages. Message definitions and sets in the flow are converted into anXML message for the partners. Due to the large amount of data, multipleflows may be used for rapid processing. Several message flow instancesare initiated.

The third, ExecutionGroup3, allows purging of the messages on thePartner queues if the messages are not being read. This is a simpleexecution group containing, for example, purge flows for the variouspartners 107.

Finally, ExecutionGroup4, controls the permissions, fulfillment, audittools, and email utilities for exception handling. This execution groupcontains miscellaneous utilities such as Auditing, Email Alerts, andFulfillment flows. Permissioning is used to identify partnersubscriptions to each data set (News & Pricing, Analytics, etc.). Afulfillment system generates a permission file and sends the file to apermission feed queue. This message is read by the permission flow anddata is refreshed in a database instance in the TPF engine. This data isused, for example, by an Exchange Web Services (EWS) flow to mappartners to each incoming message item to determine data recipients. Anaudit tool determines the number of messages processed.

More specifically, as shown in FIG. 2, a message arrives into theapplication feed queue node 201 and is routed to a Flow Order 202 nodeby the TPF engine. The Flow Order 202 node regulates the message flowand routes the message to a CheckEWSType node 204.

As shown in FIG. 4, the check content type node 204 (CheckEWSType)determines the message type and routes the message to the appropriatenode for its message type. For example, this message flow determineswhether an XML input message is textual, numeric or metadata by checkingfor the corresponding tag. This is a commonly used flow across allmessage flows. Textual messages are recognized by the presence of <page>tag (482) and are routed for textual processing (484), for instance, tothe Build Textual Data 210 node shown in FIG. 2. Price messages arerecognized by the presence of the <num> tag (486) and are routed andprocessed according to a numeric flow. For instance, price messages maybe checked for pricing errors (488). Similarly, metadata messages may bechecked for metadata errors (490).

More specifically, the Check Pricing Errors node 208, shown in FIG. 2,checks the message for errors, missing mandatory information (Symbol,DataPoint, PermCode, DateTime, Date, Trans Attributes), and invalidpermission codes. It then processes the price point list to send thevalid entries and propagate the message to a node for building the pricedata.

A Build Price Data node 212 builds the individual messages for eachpartner based on the permission code and the subscription details in thePermissions table. If there is no vendor subscribing to this categorythe message is sent to a NOSUBSCRIPTION queue 228. The node transformsthe date format and trans code (to New from Resend for the Future priceassessments that are resent the next day) and sends the message to theVendor Destination node 216, which in turn routes it the appropriatepartner queue(s) depending on the permission file. The message will besent to an error queue if there are no price point elements.

The Build Textual Data node 210 validates the tags in the message andbuilds the individual textual messages for each partner based on thepermission code and the subscription details in a Permissions table. Ifthere is no vendor subscribing to this category the message is sent to aNOSUBSCRIPTION queue 228. If there are vendors subscribing to thiscategory, then node 210 transforms the date format, and appends tagssuch as service type, service code etc. Exemplary tags according to anaspect of the present invention, including path, description, andapplicable rules, are provided in Table 3. The node 210 then builds theindividual vendor specific message and then propagates it to the VendorDestination node 216.

A Process MetaData node 214 builds a metadata message, when appropriate,for each partner in a similar fashion to the Build Price Data node andsends the message to the Vendor Destination node 216.

The Vendor Destination node 216 routes the message to the appropriatephysical queue. An exemplary high-level architecture according to anembodiment of the present invention, including vendors, is shown in FIG.3. This high-level architecture shows a textual and price datageneration system in communication with at least one TPF, which is incommunication with at least one of a plurality of vendors. If a queueexists, and there are no errors or exceptions to prevent or otherwiseinterfere with delivery, the Vendor Destination node 216 routes theoutput message to the Populate Env Fields node 218. Otherwise themessage is sent to the Populate Env Fields On Error node 220. ThePopulate Env Fields node 218 prepares the message for auditing. Forexample, node 218 may set environment variables for auditing purposes.The Populate Env Fields On Error node 220 verifies exceptions and errorsto the partner queue and populates the necessary environment fields tosend the message to error processing.

As shown in FIG. 5, an error handling node 222 may be used for exceptionhandling and error reporting. For example, this message flow may beconfigured to receive an error, build an error message, log it to a filefor reference, and determine whether to send an email or not based onthe log level. According to embodiments of the present invention, thisis a flow that can be used across all the message flows. The Build ErrorMessage node 501 forms the error message and logs it. The error messagemay specify in a text/XML file whether it is an unknown exception oranother exception and may specify the timestamp, message id, and thecontent of the error message. The Log To File node 503 logs the errormessage and propagates this message to the Send Email node 505.Depending on the error flag, the Send Email node 505 either logs themessage to a Failed-to-send-Mails log 507, or unsent email queue 509, orsends it for email output. The Email Output node 511 sends the email tothe designated email address via the assigned mail server. Failures andexceptions may be logged, as well as the reason for, or detailsregarding, any failures in mailerror.log 513.

As shown in FIG. 6, a Load Permission File Flow may be used to load thepermission codes from a fulfillment system into a permissions database858. The file received is parsed and the details are uploaded into thedatabase table. The unique design of the TPF rule engine 101 allowsreal-time application of business rules and business changes. Forinstance, this message flow architecture allows the system to maintainsubscription details in real time by processing the permission file 857,as designed by the fulfillment system. For example, the Load PermissionFile message flow may process the permission file 857 in real timewhenever there is a change in the incoming permission file 857 byprocessing the details and updating the permission database 858.

As shown in FIG. 7, a Perfmon Results Flow may be used to recordperformance statistics of the delivery system. Performance statisticsmay include, for example, time to delivery for a vendor or thedifference in delivery times between vendors. The audit flow may includechecking for a performance flag or other indication of performance.After the audit flow, each message is sent to a performance monitoringqueue. If performance monitoring is turned on, the results are built andlogged.

As shown in FIG. 8, a Send to Audit Flow 226 is used to log the auditresults. After processing for partner transmission, the message isreceived by the Build Audit Message node 801, which builds the messageneeded for audit logging and sends it to the audit log queue 803.Auditing is turned on by sending the XML messages to ISO and applicationaudit logging utilities. This change can be logged in the audit log aswell by using the Log Logger Level node 805.

As shown in FIG. 9, in an audit data log flow, once the message reachesthe Audit Log queue 803, it is logged and propagated to the PerformanceMonitoring queue 805 to record performance details. If there are anyerrors, an error message can be saved.

An exemplary Messaging Structure according to an embodiment of thepresent invention is shown in FIG. 10. According to an embodiment of thepresent invention, the system uses the custom, simplified XML tag setshown in FIG. 10 to deliver real-time textual and numeric contentdirectly to a plurality of subscribers. This XML tag set specifies allof the information needed to package, process, and distribute real timecontent messages and includes an advanced tagging structure that allowsgranular content customization and flexibility.

In this example, the root element of the XML data is the <message> tag.This contains four of six possible child elements: the first, second andthird tags—<sendTo>, <sendDt> and <service>—are required in allmessages. The fourth tag is either <num> OR <page> OR <metaData>. Allreal-time messages take one of the following forms:

Numeric Message Form

<message>   <sendTo> ... </sendTo>   <sendDt> ... </sendDt>   <service>... </service>   <num> ... </num> </message>

Page Message Form

<message>   <sendTo> ... </sendTo>   <sendDt> ... </sendDt>   <service>... </service>   <page> ... </page> </message>

Metadata Message Form

<message>   <sendTo> ... </sendTo>   <sendDt> ... </sendDt>   <service>... </service>   <metaData> ... </metaData> </message>

An XML Tag Element Hierarchy diagram 120 that includes the <message> tagand its children is independently shown in FIG. 11. FIG. 11 shows onlythose tags that are common to all messages, according to an embodimentof the present invention.

In FIG. 12 is an XML Tag Element Hierarchy Diagram 122 illustrating theparent-child relationship of the XML <page> tag used for textual newsstories. The <page> tag is not used for numeric or formatted data.

In FIG. 13 is an XML Tag Element Hierarchy Diagram 124 illustrating theparent-child relationship of the XML <num> tag used for both News &Pricing and Analytics data through both the <num> and <dataPoint> tags.These messages are similar, except that the Analytics data may includeadditional attributes.

In FIG. 14 is an XML Tag Element Hierarchy Diagram 126 illustrating theparent-child relationship of the XML <metadata> tag used for news andpricing metadata.

Business Rules

Textual business rules support the distribution of news, marketcommentary, transactions, and proprietary assessment and fundamentalstables pertinent to each defined market. These rules may be directed todetermining message date and time characteristics, distributing aperiodic “Heartbeat” page, setting standard textual pagecharacteristics, including required and optional tags for Textual Pages,assigning unique page identification tags, implementing processing rulessuch as transmission or storage rules, implementing display rules,providing delete/overwrite instructions, and/or topic and company codes.

Table 1 includes a listing of exemplary business rules that may beapplied by the TPF rule engine for processing textual messagesassociated with a data feed, such as a real-time XML feed in accordancewith the present invention.

TABLE 1 Textual Business Rules Message Rule ID Type Short DescriptionRule(s) BRPL01 Text Message date and time Unless otherwise stated, usecharacteristics <sendDt> as the master timestamp to store textualmessage content. BRPL02 Text XML DD “heartbeat” System distributes a“heartbeat” page page every three (3) minutes using the values <cSource>= “PGA” and <pageNumber> = “0242” to verify connectivity. The heartbeatshould never be displayed on the user screen. BRPL03 Text Standardtextual page BRPL03.1 <message> <page> characteristics identifies themessage as a textual page. BRPL03.2 Maximum page width = 80 columnsBRPL03.3 Maximum headline width = 120 columns BRPL03.4 Page length isdetermined by the content; it does not exceed twelve (12) kb(approximately 320 rows). BRPL04 Text Required tags for All textual Pagetransmissions must Textual Pages contain the following tags: <message>,<sendTo>, <sendDt>, <service>, <page>, <headLine>, <date>, <pageNumber>,<sid>, and <cSource>. BRPL05 Text Optional tags for Textual Pagetransmissions can Textual Page contain any of the following tags:<textBody>, <dateLine>, <author>, <banner>, <company>, <topic>,<cSource2>, <serviceCode>, <pCategory>, <cont>, <delete>, <flash>,<flashFollow>, <overWrite>, and <take>. BRPL06 Text Unique Page BRPL06.1Each page is uniquely Identification identified by the combination ofthe <cSource>, <pageNumber> and <sid> tags. BRPL06.2 Pages areidentified by concatenating the <cSource> and <pageNumber> tags forstorage and recall purposes. The <sid> tag differentiates versions ofeach page BRPL06.3 A sequential <sid> value is assigned to every textualpage transmission, independent of the underlying textual content. The<sid> values repeat after 999,999 page transmissions. This happensapproximately monthly. BRPL06.4 If a published page needs to becorrected or deleted pursuant to BRPL14 or 15 below, XML DD will do sowithin a few days of the original page transmission to ensure thecorrect <sid>, <cSource>, <pageNumber> combination can be found. BRPL07Text How to process pages BRPL07.1 If a page transmission that includethe includes the <cSource2> tag, then <cSource2> tag replicate thecontent for each service identified. This is in addition to the normalprocessing of the <cSource> value. BRPL07.2 Each value in the <cSource2>tag should be combined with the <pageNumber> and <sid> tags to form theadditional unique pages. BRPL07.3 Each unique combination should bestored independently for recall by the user. BRPL07.4 (Subscribersonly): Apply user permissions identified in the <cSource> or <cSource2>tags to each unique page as further defined in BRPL16. BRPL08 Text XMLDD Newswire BRPL08.1 Newswires often exceed pages the maximum file sizeand/or page height allowed by most systems. Therefore, XML DD breaksindividual Newswire transmissions into multiple smaller pages. BRPL08.2XML DD embeds codes in the <topic> tag in each individual pagetransmission. These tags contain instructions for building the newswirefrom the individual pages. This allows end-users to view an entirenewswire as a single story at the user interface. BRPL 08.3 To view anewswire as a single story, systems should process the <topic> tag codesas follows: Topic codes are in the following format: P###S#O# “P” standsfor “Page” “###” represents the starting page number of the sequence“S#O#”; S# = the current page's sequence number “O = of” and the second“#” = the total number of pages in the group. Append each sequentialpage (“S#”) in a series, as defined by the “P###” combination for anyunique <cSource> to the previous sequential page with the same topiccode (but with a different sequence number). To identify the finalNewswire sequence, concatenate the <cSource> and <pageNumber> valuesfrom the first page in the series pursuant to BRPL06. BRPL09 Text How todisplay a textual BRPL09.1 A textual Story must Story on a terminal ordisplay the <headLine> followed by client application the <textBody> andthen the <banner>. BRPL09.2 The <banner> tag defines the service name.It is center-aligned at the bottom immediately after <textBody> BRPL10Text How to display a textual BRPL10.1 XML DD distributes Storycontaining textual pages in multiple messages, continuation pages on ausing a <cont> tag to identify the terminal or client follow-on orcontinuation page. The application value in the <cont> tag correspondsto the 1-4 digit page number of the next page. Please note: the 1-4digit page number is not always the same as the <pageNumber> tag value.It may also include a <cSource> reference. BRPL10.2 The <cSource> or<cSource2> value of the originating page should always be the same asthe continuation page. BRPL10.3 Each page in a continuation series canalso contain a <take> tag that identifies the sequence number of theassociated page and the starting page number of the sequence separatedby a space. BRPL10.4 The <take> and <cont> tags are displayed in thefooter of the associated story page along with the <banner> tag. The<take> is aligned to the far left of the footer, <banner> is in themiddle and <cont> is to the far right. Note: Some applications allow theuser to navigate to the next page by clicking the <take> or <cont>values within the footer. BRPL11 Text How to identify and BRPL11.1Messages with a NULL- process a Newsflash valued <flash> tag are NewsFlashes. textual message News Flashes are urgent headlines sent whileXML DD editors develop the full story. BRPL11.2 XML DD follows most NewsFlash pages with a “Flash- Follow” page within five (5) to sixty (60)minutes of the News Flash transmission. BRPL11.3 The Flash Follow ALWAYScontains the same <sid>, <cSource>/<cSource2>, and <pageNumber> valuesas the original News Flash. BRPL11.4 A Flash Follow usually contains thesame <headLine> value as the News Flash. However, XML DD may distributea News Flash without a “Flash-Follow”. BRPL12 Text How to identify andBRPL12.1 Any message with a store a Flash-Follow NULL-valued<flashFollow> tag is a textual message Flash Follow. A Flash Follow isan update to a News Flash. BRPL12.2 Since a Flash Follow is an update toa News Flash, XML DD requires subscribers to append the <textBody> ofthe Flash Follow to the original stored News Flash. BRPL12.3 A FlashFollow contains the same <sid>, <cSource> and/or <cSource2>, and<pageNumber> values as the original News Flash. BRPL12.4 The <textBody>of the original News Flash message (if one was sent) with matching<sid>, <cSource> and/or <cSource2> and <pageNumber> values should bereplaced with the <textBody> of the Flash Follow message and remainstored relative to the <sendDt> of the original News Flash message.BRPL12.5 In addition to BRPL12.3, the Flash Follow message should alsobe stored as an independent new message relative to the <sendDt> valueof the Flash Follow message. BRPL13 Text How to display of a BRPL13.1Subscriber platforms News Flash Headline MUST differentiate News Flashheadlines from normal headlines. Note: This can be achieved in numerousways. For example by using different text font/color for News Flashes,using “Alert”-style pop-up windows, etc. BRPL13.2 XML DD requiressubscriber platforms to insert the word “NEWSFLASH:” in front of thevalue for the <headLine> tag of a News Flash. BRPL14 Text How toidentify and BRPL14.1 A DSI message is an process a Delete Storyinstruction to delete a previously sent Instruction (DSI) textualmessage and includes a message NULL-valued <delete /> tag. BRPL14.2 Uponreceipt of a DSI message, search for a previous textual message withmatching <cSource> / <cSource2>, <pageNumber> and <sid> values anddelete the original message completely. BRPL14.3 An explanation of thereason for the deletion may be contained in the <textBody> tag of theDSI message. BRPL14.4 A DSI can only occur within 24 hours followingdistribution of the original textual message. BRPL15 Text How toidentify and BRPL15.1 An OSI message is an process an Overwriteinstruction to overwrite a previously Story Instruction (OSI) senttextual message and includes a NULL-valued <overWrite /> tag. BRPL15.2Upon receipt of an OSI message, search for a previous textual messagewith matching <cSource> / <cSource2>, <pageNumber> and <sid> values andoverwrite the original message with the new OSI message. BRPL15.3 An OSIcan occur up to seven (7) days after the original story transmission.BRPL15.4 An explanation of the reason for the OSI message may becontained in the <textBody> of the OSI. BRPL16 Text How to permissionXML DD affixes tags that can be used textual content to filter and/orprovision content to (Subscribers only) end-users. BRPL16.1 Most Legacysubscriber platforms filter content for provisioning XML DD servicesusing the <cSource>/ <cSource2> tags. Only messages containing a productor service value matching an individual user's permissions, as providedby XML DD, should be accessible by the user. BRPL16.2 XML DD introducedthe new <serviceCode> tag to replace the use of <cSource> and <cSource2>for provisioning XML DD services. The <serviceCode> tag contains one ormore pre-defined XML DD service codes corresponding to the targetproduct or service. Only messages containing a product or service valuematching an individual user's permissions, as provided by XML DD, shouldbe accessible by the user. BRPL16.3 XML DD is introducing a<permissionCode> tag for future provisioning of XML DD services. Thiswill segregate each service into smaller groups of pages that can bebundled to build a product or service using one or more <permissionCode>values. This will require subscribers to maintain mappings of individual<permissionCode> values that comprise a product or service and filtermessages to the end user accordingly. BRPL17 Text Topic codes BRPL17.1XML DD uses the <topic> tag to distribute topic codes BRPL17.2 Topiccodes indicate that the content belongs to specific categories such asgeographical regions, and/or general subjects or markets. Userstypically use Topic codes to filter the content at the user interface.BRPL18 Text Specialty Topic Codes If <topic> = “XXX” the listeningservice or platform should omit the story from any scrolling headlinestack(s) at the user interface level only. BRPL19 Text Company Codes The<company> tag is used to disseminate codes within textual messagescorresponding to a specific company or other entity. This code istypically used to filter textual content. BRPL27 Text News pageCorrections BRPL20.1 A Correction message is an instruction to overwritea previously sent textual message and includes a NULL-valued <correct />tag. BRPL20.2 Upon receipt of a Correction message, search for aprevious textual message with matching <cSource> / <cSource2>,<pageNumber> and <sid> values and overwrite the original message withthe new Correction message. BRPL20.3 A Correction can occur up to seven(7) days after the original story transmission. BRPL20.4 An explanationof the reason for the Correction message may be contained in the<textBody> of the Correction BRPL20.5 When a Correction is received, itshould be displayed relative to the <sendDate> value of the latestCorrection. Any reference to the original message should be removed.

Similar to the Textual Business rules, Numeric Business rules supportthe distribution of News & Pricing data as well as Analytics data. Theserules may be related to, for example, identifying a numeric pricemessage, process and storing date references for numeric updates,identifying message transaction type, identifying and processing adeletion, determining permission for numeric content, identifying pricevalue confidence, and/or differentiating data delivery timing.

Table 2 includes exemplary business rules that may be applied by the TPFrule engine for processing numeric messages associated with a data feed,such as a real-time XML feed in accordance with the present invention.Some of the rules may apply to all numeric message types, while othersmay be more applicable to only news and pricing or analytics data.

TABLE 2 Numeric Business Rules Short Message Description Type ShortDescription Short Description BRPL20 News & How to identify a Numerictransmissions must Pricing; numeric price message contain the followingtags: Analytics <message>, <sendTo>, <sendDt>, <service>, <num> and<dataPoint> BRPL21 News & How to process and BRPL21.1 The <sendDt> tagPricing; store date references provides the date and time that Analyticsfor numeric updates XML DD distributed the update. BRPL21.2 The dateTimeattribute of the <dataPoint> tag provides the date and time to updatethe associated time series database. BRPL22 News & How to identify theAll numeric messages include a Pricing message transaction transattribute defining the type “transaction” type. trans value DescriptionC Correction N New Update D Delete R Resend BRPL23 News & How toidentify and A <dataPoint> value = “−999999” Pricing process a deletionthat includes a trans attribute with a value = “D” (delete) means theassociated instrument update, including the date, should be deleted fromthe database. BRPL24 News & How to permission XML DD includes severalattributes Pricing numeric content that can be used to filter and/or(Subscribers only) provision numeric content to end- users. BRPL24.1Each numeric message contains a permCode attribute, containing a datacategory. This attribute is used to bundle groups of instruments intoprice data packages. Proper processing and storage of this field isrequired. XML DD can provide detailed package definitions upon request.BRPL25 Analytics How to identify the Currently, most ISOs report onlyprice value confidence preliminary and settlement prices. Preliminaryprices are reported first. One ISO-PJM-also reports ‘ADVISORY’ prices,which are followed by ‘PRELIMINARY’ and then ‘SETTLEMENT’ prices. In thefuture, more ISOs are likely to adopt ‘ADVISORY’ prices. For example,Every hour, a price for a subset of PODs is reported. These areconsidered “ADVISORY” prices. At the start of each business day, PJMreleases “PRELIMINARY” prices for the previous day. Any record that hadan ADVISORY price reported gets updated with the PRELIMINARY price. Ifthere was no ADVISORY for a POD, a new record is created. Most, but notall, PODs have Preliminary prices. On the fourth or fifth business dayof the month, “SETTLEMENT” prices are released for the previous month.Any record having an ADVISORY or PRELIMINARY price will be updated withthe SETTLEMENT price. If there was no ADVISORY or PRELIMINARY price fora POD, a new record is created. Not all PODs have settlement prices.BRPL26 News & How to differentiate XML DD maintains data deliveryPricing or data delivery timing business models based on the timingAnalytics for a specific user of delivery to an end-user, e.g. XML DDMarket Data uses multiple “cut-times” to deliver different regional datacategories, whereas the same data is distributed in real-time via thisXML data feed. To differentiate business models, XML DD introduced the“type” and “releaseTime” children to the <service> tag. The “type” valuecorresponds to the business model, while the “releaseTime” valuecorresponds to the time that the data may be released to users of thecorresponding service “type”. Consumers that wish to consolidate receiptof XML DD content on the XML feed and support/offer multiple XML DDbusiness models must do the following: Maintain user information thatcontains the user's service “type”, e.g. real-time versus XML DD MarketData Match data delivery timing to service type as defined by XML DD

Message Distribution Process

Once the message for a subscriber (vendor, partner) is built, themessage is delivered over a public or private network to the appropriatedestination. After an acknowledgement is received from the destination,the next message is delivered. If there is a network disruption and theacknowledgment is not received, the message transfer is rolled back andthen delivered when the connectivity is back up.

According to an aspect of the distribution process of the presentinvention, each message can be delivered in real-time, globally, to anydesired destination. For instance, messages from a content generator canbe dynamically transformed, packaged, processed, and distributed all inreal-time (e.g., as they are received), rather than being stored, andthen retrieved at a later time for distribution to a particularsubscriber. Further, the system allows setting a priority level to eachmessage so that a better performance can be achieved by transferring thehigh priority messages first. In certain embodiments, messages arequeued up at the source until a successful transmission is made, whichensures that no data is lost when the destination system is notavailable. Moreover, the messaging system allows reliability andaudit-ability of the data sent because each message can have its ownmessage ID and a correlation ID, which allows unique message transferand associated statistical data, for instance, data regarding when themessage was delivered.

According to an aspect of the present invention, a custom and simpleDocument Type Definition (DTD) for the XML system is used. Each XML tagspecified within the DTD for the XML Element Hierarchy, illustrated inFIG. 10, may be divided into subsections representing major DTDcategories, such as: Message tags (common to all messages); Numeric tags(News & Pricing data); Numeric tags (Analytics data); Textual tags; andMetadata tags (News & Pricing and Analytics). The Element HierarchyDiagram (FIG. 10) is used to illustrate exemplary parent-childrelationship of complex types.

Table 3 provides tag names, the paths, as well as a description for eachtag, including applicable rules. It also contains content data type,sample values (if appropriate), frequency of tag occurrence, itsattributes, and sub-elements, if any. If the tag does not have anyattributes or sub-elements, then those sections are excluded from thelisting. The DTD Source is used only for complex tag types.

TABLE 3 Path Tag Name Description Root element. <message> This is theroot element of anXML message. It indicates the start and end of amessage. <message> <sendDt> Tag indicating the date and time that ofmessage distribution. The value from this tag should be used as the<dataPoint> dateTime attribute for storing numeric News & Pricingmessages. <message> <sendTo> Tag indicating partner distribution.<service> Parent tag providing service “type” and release timinginstruction related to underlying message. The “type” attributeidentifies the specific delivery type, e.g. real-time versus end-of-day,while “releaseTime” provides the date and time that the message may bereleased to end-users. This is for Partners only. <message> <dataPoint>Contains the data point value and descriptive <num> attributes. Requiredfor <num> message types. It represents the price at a given point intime Identifies the message as numeric data (versus textual content).Used to update a time-series database of the referenced instrument(<symbol>). <message> <author> Specifies the name of the provider of thepage <page> content. <message> <banner> The name of the service themessage is associated <page> with. Part of the display in a properlyformed page. <message> <company> A tag containing one or more codesrepresenting <page> specific entities or companies referenced in a page.Provides mechanism for filtering articles by company at the userinterface. <message> <cont> The <take> and <cont> tags may be usedtogether to <page> distribute associated textual stories as a series oflinked pages. The <cont> tag identifies a “continuation” page. Its pagenumber reference uses the same <cSource> or <cSource2> value as theoriginating page. <message> <cSource> Contains the 3-letter service codethat in <page> combination with the <pageNumber> tag identifies a uniquepage of content. It is used for permissioning textual content. <message><cSource2> Contains the 3-letter service code that in <page> combinationwith the <pageNumber> tag identifies a unique page of content. Used onlywhen multiple service codes are assigned to the underlying textual pagetransmission. It processes the associated page and store two (2) copies;one associated with <cSource> and one associated with <cSource2>. Eachcopy is treated as unique content for permissions and privilegingpurposes <message> <date> Indicates the date and time a textual page is<page> published. YYYY-MM-DDThh:mm:ss.sTZD. hh = two digits of hour (00through 23) (am/pm NOT allowed) mm = two digits of minute (00 through59) ss = two digits of second (00 through 59) s = one or more digitsrepresenting a decimal fraction of a second TZD = time zone designator(Z or +hh:mm or − hh:mm) <message> <dateLine> The geographic locationwhere the story originated. <page> <message> <delete> Indicates the pagecontent is to be deleted. Deletes <page> any previous instance of a pagetransmitted with the same <sid>, <cSource> and <pageNumber> valuesduring a 24 hour period. <message> <flash> Identifies textual pagecontent as a “News Flash”. <page> News Flashes are used to communicatelate breaking news or market events while the story is being developed.They typically do not contain a <textBody> tag. The system may (but isnot required to) transmit the full story details (known as a “FlashFollow”), which. includes the <textBody> tag within one (1) hour of theNews Flash message using the same story identification tag values.<message> <headLine> Required. Contains text used to foam the headline<page> for a News Story, Flash or Flash Follow. <message> <overWrite>Tag instructing overwriting of a previously <report> <page> distributedpage. Overwrite any previous instance of a page transmitted with thesame <sid>, <cSource> / <cSource2> and <pageNumber> values during a 24hour period. <message> <page> Tag used for textual news stories.Identifies the start and end of the textual data for all news stories.It is not used for numeric market data or formatted data <message><pageNumber> Tag used with <cSource> to define a specific textual <page>page. These two tags are typically used to search for or recall pages ofcontent at the user interface. Combining <cSource>, <pageNumber> and<sid> tags provides a mechanism for storing any version of a specificpage. <message> <pCategory> Optional tag defining the category of pagetype that <page> the underlying page belongs to <message> <serviceCode>Tag listing service or services to which the <page> underlying textualmessage belongs. Used for textual content privileging and permissionspurposes by the system and Partners. <message> <sid> Story Identifier. Aunique seven-digit number <page> assigned to every textual pagetransmission. This tag is critical for version control. <message> <take>The <take> and <cont> tags may be used in tandem <page> to distribute aseries of associated textual stories. The <take> tag contains the pagesequence number within the series, followed by the page number thatstarts the series. <message> <textBody> Tag used to encapsulate the bodytext of any given <page> textual page, e.g. contains the actual story.Although most updates include this tag, it is optional and appliessolely to textual messages. <message> <topic> Tag that associatestextual content with desired <page> subject, category or group, e.g.specific geographical region and/or general subject or market. Used tofilter content by desired “topic”. <message> <conv> Optional tagcontaining information for converting <metaData> price values from oneunit of measure to another) <peimissionCode> based on commodity-specificcharacteristics such <ewsSymbol> as specific gravity. <message><ewsSymbol> Tag containing one symbol that is part of the parent<metaData> permission code. Each permission code can have<permissionCode> many ewsSymbol tags. <message> <metaData> Container forNews & Pricing metadata. <message> <optAttr> Optional tag containingdescriptive attributes related <metaData> to <ewsSymbol> such ascommodity, location, <permissionCode> delivery period, etc. <ewsSymbol><message> <permissionCode> Two or three digit code that groups the News& <metaData> Pricing symbols together for permissioning Provisions andfilters numeric messages by data category. <message> isoSymbol Theunique identifier that represents a point of <metadata> delivery andfrequency type. <permissionCode> <message> <metaData> Container forAnalytics metadata. <message> <permissionCode> This tag is for internalprocessing purposes. It is <metadata> represented as a 2 or 3 digit codethat groups the Analytics and News & Pricing symbols. It is used todetermine what content the customer will receive.

In accordance with another aspect of the invention, at least two typesof messages (textual and numeric) can be received. The following areexamples of transforming an input document, the process for tag mappingeach type of message, and generated output documents.

Example 1 Textual

An exemplary input document, for example, from the textual data queue,which can be processed in accordance with the present invention, isshown below:

<?xml version=“1.0” encoding=“UTF-8”?> <!DOCTYPE MESSAGE [ <!-- thisdocument is not valid --> ]> <MESSAGE>  <SEND_DT>2010061101:03:54</SEND_DT>  <REPORT>  <PRIORITY>1</PRIORITY>  <SOURCE>   <EW>   <SERVER>sgcplew</SERVER>    <DBREPLICA>852566ad0056a9ec</DBREPLICA>   <UNID>186263C390C06BF88525773F001BCC1F</UNID>   </EW>  </SOURCE> <DESTINATION VENDOR=“BLOOMBERG” FORMAT=“PLATTS”>  <IDENTIFIER>01</IDENTIFIER>   <FEEDBANNER>--Platts GlobalAlert--</FEEDBANNER>  </DESTINATION>  <DESTINATION VENDOR=“COMSTOCK”FORMAT=“COMSTOCK”>   <FEEDBANNER>--Platts Global Alert--</FEEDBANNER>  <FEEDTOPIC>ML,OPC,QA,PET,N,QQ,PET,PROD,PLTN</FEEDTOPIC> </DESTINATION>  <DESTINATION VENDOR=“TELERATE” FORMAT=“PLATTS”>  <IDENTIFIER>01</IDENTIFIER>   <FEEDBANNER>--Platts GlobalAlert--</FEEDBANNER>   <FEEDTOPIC />  </DESTINATION>  <DESTINATIONVENDOR=“EMIS” FORMAT=“EMIS”>   <FEEDBANNER>--Platts GlobalAlert--</FEEDBANNER>  </DESTINATION>  <DESTINATION VENDOR=“KR”FORMAT=“PLATTS”>   <IDENTIFIER>01</IDENTIFIER>   <FEEDBANNER>--PlattsGlobal Alert--</FEEDBANNER>  </DESTINATION>  <DESTINATION VENDOR=“NTM”FORMAT=“NTM”>   <IDENTIFIER>PL</IDENTIFIER>   <FEEDTOPIC>MEAST OPEC QACRU PLTN CRU PROD PLTN</FEEDTOPIC>  </DESTINATION>  <DESTINATIONVENDOR=“PCN” FORMAT=“PLATTS”>   <COMSTOCKEXCHANGE />  <FEEDBANNER>--Platts Global Alert--</FEEDBANNER>   <NOPAGENUMBER />  <PRODUCT>PCN</PRODUCT>   <FEEDTOPIC>MEAST OPEC QA CRU N ENY PGA CRUPROD PLTN</FEEDTOPIC>  </DESTINATION>  <PAGE>   <HEADLINE>109--Tenderdata: Tasweeq offers 4.8 mil barrels Aug Al-Shaheen crude</HEADLINE>  <TEXT_BODY>Singapore (Platts)--11Jun2010/103 am EDT/503 GMT Seller:Tasweeq Country: Qatar Specs &amp; quantity: Eight cargoes of heavy sourAl-Shaheen crude,     each 600,000 barrels Port: FSO Astro Canopus When:Loading Aug 1-2, Aug 3-4, Aug 7-8, Aug 9-10, Aug 16-17, Aug 21-22,   Aug22-23, 25-26 Basis: Differential to front line Platts Dubai assessmentClose: June 14, with validity until June 17 Data from: Trade sourceNotes: Tasweeq last sold nine parcels of Al-Shaheen crude, each 600,000barrels, loading in July at discounts of about $1.00-1.20/barrel toPlatts Dubai assessments. Buyers were said to be majors ExxonMobil,Japan's Nippon Oil and Thailand's PTT. --Wendy Cheong,wendy_cheong@platts.com</TEXT_BODY>   <DATE>20100611 01:03:54</DATE>  <DATELINE>Singapore</DATELINE>   <AUTHOR>wcheo</AUTHOR>  <PAGEHEADER>MH0109</PAGEHEADER>   <BANNER>--Platts GlobalAlert--</BANNER>   <PAGEWIDTH>78</PAGEWIDTH>  <PAGEHEIGHT>120</PAGEHEIGHT>   <TOPIC>MEAST OPEC QA CRUN ENY PGA CRUPROD PLTN</TOPIC>   <SID>7649836</SID>   <CSOURCE>PGA</CSOURCE>  <CSOURCE2>PPN</CSOURCE2>   <MRIC>PGA109</MRIC>  <NATTRIB>PLATTS</NATTRIB>   <NPRODUCT>PGA PGT</NPRODUCT>  <NSTYLE>3</NSTYLE>   <PCATEGORY>NW</PCATEGORY>  </PAGE>  </REPORT></MESSAGE>

Upon receipt of a textual input message, such as the message above, bythe message flow, the following processing may be performed:

First, the message is propagated to a “Check Content Type” node, which,for example, may run the CheckEWSType message flow shown in FIG. 4. Inthis example, the message would be identified as “Textual” message basedon the presence of the “PAGE” tag.

The message is then routed to a “Build Textual Data” node, such as node210 shown in FIG. 2. This node may verify that the message includesvalid tags, check for any missing tags, and route the message to anerror queue if there is a missing tag. If there are valid tags, a secondcheck is then performed to verify the vendors who subscribe to thiscategory of message. Each vendor has the permissions set up against the<cSource> tag. If there are no vendors who subscribe to the <cSource>tag in the incoming message, the message is sent to a no-subscriptionqueue. If there are subscribing vendors, then individual messages arecreated from one input message to each individual vendor with a separate<sendTo> tag.

All the incoming tags are not necessarily translated. However, thefollowing tags may be picked up from the input message, and new tags maybe added, such as the <serviceType> tag, which has been included toexpand the data delivery options to more types of data in future usingthe same delivery mechanism:

<headLine> <textBody> <date> <dateline> <author> <banner> <topic> <sid><pCategory>

After the message is built for each vendor, the message is propagated toa Vendor Destination node, such as node 216 in FIG. 3. From the VendorDestination node the message is finally sent to the specific queuecreated for the vendor in the system. After completing the delivery, themessage is sent to a second flow where the audit details are captured toreport on performance and auditing information.

An exemplary output document could be as follows:

<message>  <sendTo>BACKUP</sendTo> <sendDt>2010-06-11T01:03:54-04:00</sendDt>  <service type=“RealTime” releaseTime=“2010-06-11T01:03:54-04:00”/>  <page>  <headLine>109--Tender data: Tasweeq offers 4.8 mil barrels Aug Al-  Shaheen crude</headLine>   <textBody>Singapore (Platts)--11Jun2010/103am EDT/503 GMT   Seller: Tasweeq   Country: Qatar   Specs &amp;quantity: Eight cargoes of heavy sour Al-Shaheen    crude, each 600,000barrels   Port: FSO Astro Canopus   When: Loading Aug 1-2, Aug 3-4, Aug7-8, Aug 9-10, Aug 16-17,   Aug 21-22,    Aug 22-23, 25-26   Basis:Differential to front line Platts Dubai assessment   Close: June 14,with validity until June 17   Data from: Trade source   Notes: Tasweeqlast sold nine parcels of Al-Shaheen crude, each   600,000 barrels,loading in July at discounts of about $1.00-1.20/   barrel to PlattsDubai assessments. Buyers were said to be   majors ExxonMobil,Japan&apos;s Nippon   Oil and Thailand&apos;s PTT.   --Wendy Cheong,wendy_cheong@platts.com</textBody>  <date>2010-06-11T01:03:54-04:00</date>  <dateLine>Singapore</dateLine>   <author>wcheo</author>  <pageNumber>0109</pageNumber>   <banner>--Platts Global Alert</banner>  <topic>ML,OPC,QA,PET,N,QQ,PET,PROD,PLTN</topic>   <sid>7649836</sid>  <cSource>PGA</cSource>   <cSource2>PPN</cSource2>  <serviceCode>PPN</serviceCode>   <pCategory>NW</pCategory>  </page></message>

Example 2 Numeric

An exemplary input document, for example, from the numeric data queue,which can be processed in accordance with the present invention, isshown below:

Input Document:

<?xml version=“1.0” encoding=“UTF-8”?> <!DOCTYPE MESSAGE [<!-- thisdocument is not valid -->]> <MESSAGE>  <SEND_DT>2010061101:46:35</SEND_DT>  <REPORT>  <PRIORITY>2</PRIORITY>  <SOURCE>   <EW>   <SERVER>NYWPLSA</SERVER>    <DBREPLICA>85256738005038EC</DBREPLICA>   <UNID>5C4D52536CD3BD838525773F001FBB12</UNID>   </EW>  </SOURCE> <DESTINATION VENDOR=“COMSTOCK” FORMAT=“COMSTOCK” />  <DESTINATIONVENDOR=“EMIS” FORMAT=“EMIS” />  <DESTINATION VENDOR=“KR” FORMAT=“PLATTS”/>  <DESTINATION VENDOR=“BLOOMBERG” FORMAT=“PLATTS” />  <DESTINATIONVENDOR=“TELERATE” FORMAT=“PLATTS” />  <DESTINATION VENDOR=“MARKETLINK”FORMAT=“MARKETLINK” />  <NUM>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>690</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCBDAA00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CBDAA00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CBDAA00” cSymbol=“PDB03Dc 19bCBDAA00DW2”rSymbol=“CBDAA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 690.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>690</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCBDAB00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CBDAB00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CBDAB00” cSymbol=“PDB03Dc 19bCBDAB00DW2”rSymbol=“CBDAB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 690.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00<DATETIME>    <BATE>u</BATE>    <PRICE>705</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG” >PDB03Dc 19bCBGAK00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CBGAK00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CBGAK00” cSymbol=“PDB03Dc 19bCBGAK00DW2”rSymbol=“CBGAK00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 705.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>705</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCBGAL00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CBGAL00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CBGAL00” cSymbol=“PDB03Dc 19bCBGAL00DW2”rSymbol=“CBGAL00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 705.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>569</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB3BA00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB3BA00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB3BA00” cSymbol=“PDB03Dc 19bCB3BA00DW2”rSymbol=“CB3BA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 569.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>569</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB3BB00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB3BB00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB3BB00” cSymbol=“PDB03Dc 19bCB3BB00DW2”rSymbol=“CB3BB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 569.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>516</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB8BA00DW2<SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB8BA00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB8BA00” cSymbol=“PDB03Dc 19bCB8BA00DW2”rSymbol=“CB8BA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 516.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>516</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB8BB00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB8BB00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB8BB00” cSymbol=“PDB03Dc 19bCB8BB00DW2”rSymbol=“CB8BB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 516.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>480</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB1AK00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB1AK00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB1AK00” cSymbol=“PDB03Dc 19bCB1AK00DW2”rSymbol=“CB1AK00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 480.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>480</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB1AL00DW2</SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB1AL00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB1AL00” cSymbol=“PDB03Dc 19bCB1AL00DW2”rSymbol=“CB1AL00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 480.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>480</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB3AJ00DW2<SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB3AJ00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG, MARKETLINK</xmlVendor>    <dataPoint symbol=“CB3AJ00” cSymbol=“PDB03Dc 19bCB3AJ00DW2”rSymbol=“CB3AJ00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00”bate=“u” trans=“N”> 480.00 </dataPoint>     <dtTzInfo TZ=“EST” />   </xmlFeedOnly>   </PRICEPOINT>   <PRICEPOINT>    <DATETIME>2010061100:00:00</DATETIME>    <BATE>u</BATE>    <PRICE>477</PRICE>    <SYMBOLVENDORLIST=“COMSTOCK, KR, BLOOMBERG”>PDB03Dc 19bCB3AK00DW2<SYMBOL>   <SYMBOL VENDORLIST=“MARKETLINK”>CB3AK00 860</SYMBOL>    <xmlFeedOnly>    <xmlVendor>COMSTOCK, KR, BLOOMBERG,    MARKETLINK</xmlVendor>    <dataPoint symbol=“CB3AK00” cSymbol=“PDB03Dc 19bCB3AK00DW2”    rSymbol=“CB3AK00 860” permissionCode=“BA” dateTime=“2010-06-    11T00:00:00” bate=“u” trans=“N”>477.00</dataPoint>     <dtTzInfoTZ=“EST” />    </xmlFeedOnly>   </PRICEPOINT>  </NUM>  </REPORT></MESSAGE>

Upon receipt of a numeric input message, such as that above, by themessage flow, the following processing is performed:

First, the message is propagated to a “Check Content Type” node, which,for example, may run the CheckEWSType message flow shown in FIG. 4. Inthis example, the message would be identified as a “Price1” messagebased on the presence of the NUM tag.

The message is then routed a “Check Pricing errors” node, such as node208 of FIG. 2. This node verifies the valid tags and checks for anymissing tags and routes it to error queue if there is a missing tag.This node checks the message for errors, missing mandatory information(Symbol, DataPoint, PermCode, DateTime, Date, Trans Attributes), andinvalid permission codes. Assuming there are valid tags, a further checkis performed to verify the vendors who subscribe to this dispatchcategory of message. Each vendor has the permissions set up against thepermissionCode tag.

If there are no vendors who subscribe to the permissionCode tag in theincoming message, the message is sent to a no-subscription queue. Ifthere are subscribing vendors, then individual messages are created fromone input message to each individual vendor with a separate <sendTo>tag.

All the incoming tags do not need to be translated; however, thefollowing tags are picked up from the input message: <dataPoint> tagwith symbol, dateTime, permCode, bate, and trans attributes. New tagsmay be added like the <serviceType>, <releaseTime>, and<dispatchReleaseTime>, which have been included to expand the datadelivery options to more types of data in the future using the samedelivery mechanism.

After the message is built for each vendor, the message is propagated toa Vendor Destination node, such as node 216 of FIG. 2. From the VendorDestination node the message is finally sent to the specific queuecreated for the vendor in the system.

After completing the delivery, the message is sent to a second flowwhere the audit details are captured to report on performance andauditing information.

Output Document:

<message>  <sendTo>BACKUP</sendTo> <sendDt>2010-06-11T01:46:35-04:00</sendDt>  <service type=“RealTime” releaseTime=“2010-06-11T01:46:35-04:00”/>  <service type=“Dispatch”releaseTime=“2010-06-11T08:00:00-04:00”/>  <num>   <dataPointsymbol=“CBDAA00” permCode=“BA” dateTime=“2010-   06-11T00:00:00-04:00”bate=“u” trans=“N”>690.00</dataPoint>   <dataPoint symbol=“CBDAB00”permCode=“BA” dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>690.00</dataPoint>   <dataPoint symbol=“CBGAK00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>705.00</dataPoint>   <dataPoint symbol=“CBGAL00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>705.00</dataPoint>   <dataPoint symbol=“CB3BA00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>569.00</dataPoint>   <dataPoint symbol=“CB3BB00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>569.00</dataPoint>   <dataPoint symbol=“CB8BA00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>516.00</dataPoint>   <dataPoint symbol=“CB8BB00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>516.00</dataPoint>   <dataPoint symbol=“CB1AK00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>480.00</dataPoint>   <dataPoint symbol=“CB1AL00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>480.00</dataPoint>   <dataPoint symbol=“CB3AJ00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>480.00</dataPoint>   <dataPoint symbol=“CB3AK00” permCode=“BA”dateTime=“2010-   06-11T00:00:00-04:00” bate=“u”trans=“N”>477.00</dataPoint>  </num> </message>

Example 3 Flow Details

Shown in FIG. 15 is a logical network diagram of an exemplary contentpublication system according to an embodiment of the present invention.Various types of numeric and textual content are received by at leastone Transform Publish Filter (TPF) 102, 106 from a Content GenerationSystem 110 via a computer network, such as the internet. The TPFs 102,106 transform and dynamically package the received data and publish itto at least one of a plurality of subscribers 150, 155, 160, 165 basedon a set of permissioning rules and via a network, such as the internet.

As shown in FIG. 16, textual and numeric data is generated in a ContentGeneration System 110 and delivered via a messaging protocol 115 to anXML document delivery system 100, such as the input documents shown inthe prior examples. In accordance with an embodiment of the presentinvention, the system includes a TPF 1040 that filters and packages thecontent for delivery to a plurality of subscribers. The XML deliverysystem 100 is implemented on a computerized messaging platform, such asIBM WebSphere Message Broker®. The XML delivery system 100 communicateswith the Subscriber hosts 150, 155, 160, 165 using an IP based messagingprotocol 115 such as IBM WebsSphere MQ®. The system may include one ormore servers including a dedicated and/or virtual server having memorytherein.

According to an embodiment of the present invention and as illustratedin FIG. 17, textual and numeric data from the Content Generation System110 are sent to the XML Data Feed queue 2050 on the TPF 1040. EachExecution Group shown in FIG. 17 contains named groupings of messageflows in the XML delivery system 100. In this example, a message flowmay be understood as a sequence of nodes, i.e. processing steps, thatrun on the XML delivery system 100 when an input message is received. Onthe XML delivery system 100, a node represents a set of actions thatdefine a processing step. In this configuration, the delivery system 100allows for multiple data types, such as XML textual messages 122, XMLprice messages 124, and XML metadata messages 126, to be processedsimultaneously and yet still maintain the correct sequential order. Themessage flows can process the multiple data types by filtering theincoming message types (see FIGS. 10, 11, 12).

FIG. 17 depicts the execution groups of an exemplary TPF engine 1040according to an embodiment of the present invention. The executiongroups include the EWS Execution Group 2000, the EWS-Textual ExecutionGroup 2100, the EWS-Textual-Subscriber Execution Group 2120, theEWS-Metadata Execution Group 2200, the EWS-Numeric Execution Group 2300,the EWS-Numeric-Subscriber Execution Group 2320, and a Utility ExecutionGroup 2500. The execution groups may then route data to a nosubscription node 2740, subscribers XML 2.0 data node 2700, and/or anerror queue 2780.

The EWS Execution Group 2000 sorts the data from the XML Data Feed queue205 by determining its type and routing it to the correct queue. Firstthe message type is identified (i.e., textual, numeric, or metadata),then the message is routed to the corresponding node for that messagetype, with specific tags determining the fulfillment criteria. If thereare any errors in the XML tag structure, the messages are sent to theerror queue and no further processing is done.

As shown in FIG. 17, The EWS Execution Group 2000 is the entry point forreceived messages, such as XML 1.0 messages produced by the ContentGeneration System 110. A flow, ProcessEWSFeed.msgflow 300, which isdiagrammed in FIG. 18, is the primary message flow in the EWS ExecutionGroup. The main function of the ProcessEWSFeed.msgflow 300 is todetermine which type of XML 1.0 message (i.e., textual, numeric, ormetadata) has been received, after which the message is sent to therespective message queue. According to an embodiment of the presentinvention, the messages may be processed in a series of nodes. Forexample, messages may be processed in fifteen nodes within theProcessEWSFeed.msgflow 300 as follows:

Node 1. EWSFEED.QUEUE 310—This is the input node where XML 1.0 messagesare received from the Content Generation System 110.

Node 2. FlowOrder 312—This node determines which order to processincoming messages, based on, for instance, order of receipt, content,key-words, or specific tags in the incoming message.

Node 3. DistributeXML10Msg 320—This node sends copies of XML 1.0messages to XML 1.0 Subscribers.

Node 4. XML10_DestinationList 336—This is an output node which acts as adestination list where XML 1.0 messages are sent from theDistributeXML10Msg node 320.

Node 5. TryCatch 316—This node processes exceptions, if any, occurringin the DistributeXML10Msg node 320.

Node 6. XML10_Failure Trace 318—This node logs exception messagesrelated to XML 1.0 message processing to a log file, such asxml10-Failure-Tracelog 342.

Node 7. CheckEWSType 314 (see also FIG. 4)—This is a sub message flowwhich determines the type of XML 1.0 message and routes the message tothe appropriate node. Textual messages, which may be determined by thepresence of <page> tag, are routed to the EWSFEED.TEXTUALDATA.QUEUE 334.Price messages, which may be determined by the presence of <num> tag,are checked for pricing errors and routed to EWSFEED.PRICEDATA.QUEUE332. Metadata messages are checked for metadata errors and routed toEWSFEED.METADATA.QUEUE 330.

Node 8. EWSFEED.METADATA.QUEUE 330—This is the output node to storemetadata messages.

Node 9. EWSFEED.PRICEDATA.QUEUE 332—This is the output node to storenumeric messages.

Node 10. EWSFEED.TEXTUALDATA.QUEUE 334—This is the output node to storetextual messages.

Node 11. XML1_(—)0.QUEUE.LIST 328—This is the input queue to load theXML1_(—)0.QUEUE.LIST 340 Subscriber list file to the database tableXML1_(—)0.QUEUES 342. If the XML 1.0 Subscriber list needs to beupdated, the feed file will be stored in this queue.

Node 12. InsertQueueNames 326—This node parses the XML 1.0 Subscriberfeed list 340 stored in the XML1_(—)0.QUEUES queue 328 and inserts thedata into the XML1_(—)0.QUEUES database table 342.

Node 13. Failure Trace 322—This node logs failure messages to a filesuch as Failure-Trace.log 344.

Node 14. Exception Trace 324—This node logs exception messages to a filesuch as ews-Exception-Trace.log 346.

Node 15. ERROR.QUEUE 338—This is the output node to store failuremessages.

Textual messages, such as the input message shown above, are routed to atextual data queue. According to a further aspect of the presentinvention, as shown in FIG. 19, the EWS-Textual Execution Group 2100processes the textual XML 1.0 messages within the TextualFlow.msgflowmessage flow 400. The TextualFlow.msgflow message flow 400 receives XML1.0 messages from the EWS Execution Group 2000, and then converts themto XML 2.0 format. The XML 2.0 messages are then distributed toSubscriber queues 150, 155, 160, 165. Within the TextualFlow.msgflowmessage flow 400, messages can be processed in a series of nodes. Forexample, messages can be processed in sixteen nodes:

Node 1. EWSFEED.TEXTUALDATA.QUEUE 402—This is the input node whichreceives textual XML 1.0 messages from the ProcessEWSFeed message flow300.

Node 2. FlowOrder 404—This node determines the order in which incomingmessages are processed. First a subscriber queue list, such asSubscriberQueueList file 434, is loaded. If the SubscriberQueueList file434 is null, the system builds the XML 2.0 messages and distributes themto the Subscriber queues.

Node 3. Filter 408—This node checks whether the Subscriber queue list isnull.

Node 4. EWS.SUBSCRIBER.INFLIGHT.QUEUE 410—This node retrieves messagesfrom EWS.SUBSCRIBER.INFLIGHT.QUEUE, which holds the Subscriber queuelist in XML format.

Node 5. LoadSubscriberQueueList 412—When the Subscriber queue list isnull while processing a message, this node loads the Subscriber queuelist.

Node 6. BuildTextualData 406—This node transforms XML 1.0 messages toXML 2.0 messages and then sends the messages to the Subscriberprocessing queues.

Node 7. Subscriber Destination 424—This is the output node, which sendstransformed XML 2.0 messages to subscriber-specific sub-flow nodes.

Node 8. EnvFields 426—This is a sub-flow node which saves environmentfields.

Node 9. Failure Trace 414—This node logs failure messages to a log file,such as ews-Textual-Failure-Trace.log 436.

Node 10. Exception Trace 416—This node logs exception messages to a logfile, such as ews-Textual-Exception-Trace.log 438.

Node 11. ERROR.QUEUE 430—This node is the output queue, which is used tostore error messages.

Node 12. NO.SUBSCRIPTION.QUEUE 428—This node is an output queue used tostore messages which have not been subscribed to by the Subscribers 150,155, 160, 165.

Node 13. ErrorHandler 432—This is a sub flow node used to processerrors.

Node 14. EWSFEED.TEXTUAL.CACHE.REFRESH 422—This is the input node torefresh cache data.

Node 15. Cache Reset 418—This node is responsible for resetting thecache.

Node 16. ErrorHandler1 420—This is an error handler sub message flow forprocessing errors.

The EWS-Textual-Subscriber Execution Group 2120 containssubscriber-specific message flows for processing textual messages.According to an aspect of the present invention, there may be aplurality of subscriber specific message flows. FIG. 20 shows anexemplary message flow to a specific subscriber,SubscriberProcessingSUBSCRIBER.msgflow 450. This message flow receivesXML 2.0 messages from the EWS-Textual message flow 400 and then appliessubscriber-specific logic to the message flow, before distributing it tothe Subscriber queue. Within the SubscriberProcessingSUBSCRIBER.msgflow450, messages may be processed in five nodes:

Node 1. MQInput 452—This is an input node for processing textualmessages from a specific Subscriber.

Node 2. SubscriberProcessingSubFlow 454—This message sub-flow executesSubscriber-specific logic.

Node 3. MQOutput—This is the output node for a specific Subscriber.

Node 4. ERROR.QUEUE 460—This is the output queue used to store errormessages.

Node 5. EnvFields 458—This is the message sub-flow used to populateenvironmental fields.

Numeric messages, such as the input message shown above, are routed to anumeric data execution group, as shown in FIG. 17. According to afurther aspect of the present invention, the Numeric Execution Group2300 processes numeric XML 1.0 messages using the NumericFlow.msgflow500 as shown in FIG. 21. The NumericFlow.msgflow 500 receives XML 1.0messages from the Content Generation System 110 and then converts themto XML 2.0 format, where they can be distributed to the Subscriberqueues. Within the NumericFlow.msgflow 500, messages may be processed inthirteen nodes:

Node 1. EWSFEED.PRICEDATA.QUEUE 502—This is the input node for numericXML 1.0 messages which are received from ProcessEWSFeed.msgflow 300(FIG. 18).

Node 2. FlowOrder 504—This node determines in which order to process theincoming messages, based on, for instance, order of receipt, content,key-words, or specific tags in the incoming message.

Node 3. BuildPriceData 506—This node transforms XML 1.0 messages to XML2.0 message and then sends them to the Subscriber processing queues.

Node 4. Subscriber Destination 508—This is the output node which sendstransformed XML 2.0 messages to the Subscriber queues.

Node 5. EnvFields 510—This is a sub message flow which populatesenvironment fields.

Node 6. Failure Trace 516—This node logs failure messages to a log filesuch as ews-Numeric-Failure-Trace.log 528.

Node 7. Exception Trace 520—This node logs exception messages to a logfile such as ews-Numeric-Exception-Trace.log 530.

Node 8. ERROR.QUEUE 518—This node is the output queue to store errormessages.

Node 9. NO.SUBSCRIPTION.QUEUE 514—This node is the output queue to storemessages for which there are no Subscribers.

Node 10. ErrorHandler 512—This is a sub message flow to process errors.

Node 11. EWSFEED.NUMERIC.CACHE.REFRESH 526—This is an input node forrefreshing the data cache.

Node 12. Cache Reset 522—This node will reset the cache.

Node 13. ErrorHandler1 524—This is the error handler sub message flowfor processing errors.

According to an aspect of the present invention, there may be aplurality of subscriber specific message flows. FIG. 22 shows anexemplary message flow to a specific subscriber,NumericSubscriberProcessingSUBSCRIBER.msgflow 550. This message flowreceives XML 2.0 messages from the NumericFlow.msgflow 500 and thenapplies subscriber-specific logic to the message flow, beforedistributing it to the Subscriber queue. Within theNumericSubscriberProcessingSUBSCRIBER.msgflow 550, messages may beprocessed in five nodes:

Node 1. MQInput 552—This is an input node for processing numericmessages from a specific Subscriber.

Node 2. NumericVendorProcessingSubFlow 554—This message sub-flowexecutes Subscriber-specific logic, such that unique packages may bebuilt for each subscriber.

Node 3. MQOutput 556—This is the output node for a specific Subscriber.

Node 4. ERROR.QUEUE 560—This is the output queue used to store errormessages.

Node 5. EnvFields 558—This is the message sub-flow used to populateenvironmental fields.

As shown in FIG. 23, the EWS-Metadata Execution Group 2200 isresponsible for processing metadata messages using theMetaDataFlow.msgflow message flow 600. The MetaDataFlow.msgflow messageflow 600 receives XML 2.0 messages as an input, converts them tometadata messages, and then periodically distributes them to Subscribers150, 155, 160, 165. For instance, metadata may be distributed on aweekly basis. Within the MetaDataFlow.msgflow 600, messages may beprocessed in fourteen nodes:

Node 1. EWSFEED.METADATA.QUEUE 602—This is the input node where metadatamessages in XML 2.0 format are received from the ProcessEWSFeed.msgflow300 (FIG. 18).

Node 2. FlowOrder 604—This node determines the order in which to processincoming messages, based on, for instance, order of receipt, content,key-words, or specific tags in the incoming message.

Node 3. CheckForMetaDataErrors 606—This node checks for errors in theincoming XML messages. Messages with errors are sent to the ERROR.QUEUE630.

Node 4. ProcessMetaData 608—This node transforms XML 2.0 messages tometadata messages and then sends them to the Subscriber processingqueues.

Node 5. Subscriber Destination 610—This is the output node which sendstransformed XML 2.0 messages to the Subscriber queues.

Node 6. EnvFields 612—This is a message sub-flow, which populatesenvironment fields.

Node 7. Failure Trace 618—This node logs failure messages to a log file,such as ews-MetaData-Failure-Trace.log 632.

Node 8. Exception Trace 622—This node logs exception messages to a logfile, such as ews-MetaData-Exception-Trace.log 634.

Node 9. ERROR.QUEUE 630—This is the output queue for storing errormessages.

Node 10. NO.SUBSCRIPTION.QUEUE 616—This is the output queue for storingmessages for which there are no Subscribers.

Node 11. ErrorHandler 614—This is a sub message flow for processingerrors.

Node 12. EWSFEED.METADATA.CACHE.REFRESH 628—This is the input node forrefreshing the data cache.

Node 13. Cache Reset 624—This node resets the cache.

Node 14. ErrorHandler1 626—This is the error handler sub message flowfor processing errors.

According to another aspect of the present invention, the TPF furtherincludes a Utility Execution Group 2500, which is directed to managingpartner or subscriber queues and permissioning, for example, as shown inFIG. 17. In this example, the Utility Execution group contains fivemessage flows.

The first is the LoadPartner2QueuesMapping.msgflow message flow 800,shown in FIG. 24. The LoadPartner2QueuesMapping.msgflow 800 inserts thedata from the PARTNER2QUEUES mapping file 814 into the PARTNER2QUEUESdatabase table 816. A sample of the PARTNER2QUEUES mapping file 814 isas follows:

CSQUARE |CSQRP1 TICHINA |TICHINAWithin the LoadPartner2QueuesMapping.msgflow message flow 800 are sixnodes:

Node 1. PARTNER2QUEUES.FEED.QUEUE 802—This node is the input node.

Node 2. Partner2QueuesFeed 804—This node loads the data from thePARTNER2QUEUES mapping file 814 and inserts it into the PARTNER2QUEUESdatabase table 816.

Node 3. DestinationList 806—This node writes to theEWSFEED.TEXTUAL.CACHE.REFRESH node 422, shown in FIG. 19, to refresh thedata cache.

Node 4. Failure Trace 808—This node logs the failure messages to a file,such as ews-Failure-Trace.log 817.

Node 5. Exception Trace 810—This node logs the exception messages to afile, such as ews-Exception-Trace.log 818.

Node 6. ERROR.QUEUE 812—This is the output node for saving failuremessages.

The second message flow also within the Utility Execution Group 2500 isLoadPartnerFilteringMapping.msgflow, shown in FIG. 25. This flow insertsthe data from the input file into the PARTNER_FILTERING database table835. A sample of the input file data is as follows:

REUTERS | CORRECTION_TAG | SEND BLOOMBERG | CORRECTION_TAG | SENDWithin the LoadPartnerFilteringMapping.msgflow message flow 820 are sixnodes:

Node 1. PARTNERFILTERING.FEED.QUEUE 822—This is the input node, whichreceives the data from the input file.

Node 2. Partnerfiltering 824—This node loads the data from thePARTNER_FILTERING mapping file 834 and inserts it into thePARTNER_FILTERING database table 835.

Node 3. Destination List 826—This node writes toEWSFEED.TEXTUAL.CACHE.REFRESH node 422, shown in FIG. 19, to refresh thedata cache.

Node 4. Failure Trace 828—This node logs the failure messages to a file,such as ews-Failure-Trace.log 838.

Node 5. Exception Trace 830—This node logs the exception messages to afile, such as ews-Exception-Trace.log 839.

Node 6. ERROR.QUEUE 832—This is the output node for saving failuremessages.

The third message flow within the Utility Execution Group 2500 is LoadPermission File message flow for example, as shown in FIG. 6.LoadPermissionFile.msgflow 840 inserts the data from the PERMISSIONSinput file 857 into the PERMISSIONS database table 858.

A sample of the PERMISSIONS input file 857 data is as follows:

EWS_ALL |BACKUP AA |CSQRP1 AE |CSQRP1Within the LoadPermissionFile.msgflow message flow 840 are six nodes:

Node 1. PERMISSIONS.FEED.QUEUE 842—This is the input node, whichreceives the data from the PERMISSIONS input file 857 file.

Node 2. BuildPermissionTags 848—This node loads the data from themapping file and inserts it into the PERMISSIONS database table 858.

Node 3. DestinationList 850—This node writes the permission data toEWSFEED.TEXTUAL.CACHE.REFRESH 422 (FIG. 19),EWSFEED.NUMERIC.CACHE.REFRESH 526 (FIG. 21), andEWSFEED.METADATA.CACHE.REFRESH 628 (FIG. 23), thereby refreshing thedata cache.

Node 4. Failure Trace 852—This node logs the failure messages to a file,such as ews-Failure-Trace.log 855.

Node 5. Exception Trace 854—This node logs the exception messages to afile, such as ews-Exception-Trace.log 857.

Node 6. ERROR.QUEUE 856—This is the output node for saving failuremessages.

This flow may also include a filtering node 846, which filters datareceived from input file 857 prior to uploading at node 848.

The fourth message flow within the Utility Execution Group 2500 isLoadSubscriberQMapping.msgflow 860, shown in FIG. 26. This message flowinserts the data from a VendorQMapping input file 863 into theEWS.SUBSCRIBER.INFLIGHT.QUEUE 410, shown in FIG. 19. A sample of theVendorQMapping input file 863 input file data is as follows:

CSQUARE.VO.QL | CSQRP1 TICHINA.VO.QL | TICHINAWithin the Load VendorQMapping.msgflow message flow 860 are eight nodes:

Node 1. VENDORQLIST.FEED.QUEUE 862—This is the input node, whichreceives the data from the VendorQMapping input file 863 file.

Node 2. ValidateMsg 864—This node validates the configuration of theinput data format by checking whether it is in the correct format, forinstance “VENDORQ|VENDOR.”

Node 3. ConstructMsg 868—This message flow constructs the message with aSubscriber Tag, such as:

<subscriber> <mqQName>CSQUARE.VO.QL</mqQName> <vendorName>CSQRD1</vendorName> </vendor>

Node 4. DestinationList 870—This node writes toEWSFEED.TEXTUAL.CACHE.REFRESH node 422, shown in FIG. 19, therebyrefreshing the cache data.

Node 5. PurgeQueue 872—The EWS.SUBSCRIBER.INFLIGHT.QUEUE queue is mappedto receive the constructed message.

Node 6. Failure Trace 874—This node logs the failure messages to a file,such as ews-Failure-Trace.log 877.

Node 7. Exception Trace 876—This node logs the exception messages to afile, such as ews-Exception-Trace.log 879.

Node 8. ERROR.QUEUE 878—This is the output node for saving failuremessages.

This flow may also include an additional message flow control node, 866.

LoadXMLDDTimeZoneMapping.msgflow 880 is the fifth message flow containedwithin the Utility Execution Group 2500 and is shown in FIG. 27. Thismessage flow inserts the data from the input file transfers into theXMLDD_TIMEZONE_MAPPING file 896. A sample of the XMLDD_TIMEZONE_MAPPINGinput file 896 data is as follows:

MST | US/Mountain PST | US/Pacific GMT | Etc/ZuluWithin the LoadXMLDDTimeZoneMapping.msgflow message flow 880 are sevennodes:

Node 1. XMLDD.TIMEZONE.FEED.QUEUE 882—This is the input node, whichreceives the data from the input mapping file.

Node 2. ValidateMsg 884—This node validates the input data in theXMLDD_TIMEZONE_MAPPING input file 896 configuration file, and checks forinvalid conditions, such as an empty file or invalid data format.

Node 3. Insert_TimeZone Values 886—This node inserts data into the tableXMLDD_TIMEZONE_MAPPING 898 and updates the log.

Node 4. DestinationList 888—This node writes toEWSFEED.NUMERIC.CACHE.REFRESH node 526, shown in FIG. 21, therebyrefreshing the cache data.

Node 5. Failure Trace 890—This node logs the failure messages to a file,such as ews-Failure-Trace.log 895.

Node 6. Exception Trace 892—This node logs the exception messages to afile, such as ews-Exception-Trace.log 897.

Node 7. ERROR.QUEUE 894—This is the output node for saving failuremessages.

Exemplary output messages in accordance with the above described exampleare shown in FIGS. 28 and 29. FIG. 28 shows an exemplary PriceAssessment output message, while FIG. 29 shows an exemplary News Storyoutput message.

While the invention has been described in detail above, the invention isnot intended to be limited to the specific embodiments as described. Itis evident that those skilled in the art may now make numerous uses andmodifications of and departures from the specific embodiments describedherein without departing from the inventive concepts.

1. A computerized method for delivering messages to a plurality ofsubscribers, the method comprising the steps of: receiving, at acomputerized delivery system, a plurality of incoming data messages;identifying a content type of at least one of said incoming messages;forwarding the identified messages to at least one processing nodewithin the delivery system, wherein said at least one processing node isassociated with said type of said identified message; building asubscriber-specific content message at said processing node, bydetermining a subscription permission code associated with identifiedmessages using a permissions database, and transforming the format ofsaid identified messages to a second message format; authorizing thedelivery of the subscriber-specific content message to at least one of aplurality of said subscribers based on said permission code; anddelivering said message to at least one of said subscribers inreal-time.
 2. The method of claim 1, wherein message processing withinthe delivery system is organized into execution groups, message flows,and nodes.
 3. The method of claim 2, wherein the delivery system furtherincludes a metadata message execution group, a numeric message executiongroup, and a textual message execution group.
 4. The method of claim 1,further including the steps of: checking at least one of said pluralityof incoming data messages for errors; forwarding a message to an errorqueue; building audit messages including error conditions, exceptions,and status conditions; and electronically login error conditions,exceptions, and status conditions.
 5. The method of claim 4, wherein thestep of checking messages for errors further includes checking numericmessages for missing pricepoint, symbol, datapoint, permcode, datetime,bate, trans attributes, or permission tags.
 6. The method according ofclaim 1, wherein the incoming data messages are comprised of XML marketdata with pre-defined sets of tags.
 7. The method of claim 6, whereinsaid incoming messages are in XML 1.0 format, and said deliveredmessages are in XML 2.0 format.
 8. The method of claim 1, wherein saidmessage type is one of numeric, textual, news metadata, or analyticsmetadata.
 9. The method of claim 8, wherein the step of identifying thetype of at least one of said incoming messages is accomplished using aunique XML tag set.
 10. The method of claim 8, wherein the deliveredmessages are customized for said at least one subscriber.